home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1088 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.4 KB  |  112 lines
  1. Path: fido.asd.sgi.com!austern
  2. From: feb6399@osfmail.isc.rit.edu (Frank Barrus)
  3. Newsgroups: comp.std.c++
  4. Subject: methods for accessing attributes
  5. Date: 15 Apr 1996 09:36:12 PDT
  6. Organization: Rochester Institute of Technology, Rochester, NY
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4koq35$dcd@news.isc.rit.edu>
  9. NNTP-Posting-Host: isolde.mti.sgi.com
  10. X-Original-Date: 13 Apr 1996 18:00:05 GMT
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBVAwUBMXJ6/Uy4NqrwXLNJAQGWygH7BQVUAjIgKlP83xn37Bis/Rb5tvAea67P
  13.     JI9pKhwUFhgiPXv3H6emVMwFiECW6ybQ1zlD096TH4IleODFChQJeg==
  14.     =ynK9
  15. Originator: austern@isolde.mti.sgi.com
  16.  
  17. I'm not sure if this has been previously discuessed, but so
  18. far I've seen no mention of it, so...
  19.  
  20. Has there been any consideration of adding to the standard
  21. a way of overloading access to instance variables, so that
  22. code that directly accesses a variable can be made to call 
  23. an access function if the class is modified to need it?
  24.  
  25. For instance, let's say we've got:
  26.     
  27.     class Display {
  28.     public:
  29.         int wid, hgt;
  30.     }
  31.  
  32. (with lots of other useful stuff too, but we'll omit that for now)
  33.  
  34. If lots of code already exists like the following:
  35.  
  36.     void blah(Display &d)
  37.     {
  38.         d.wid = 80;
  39.     }
  40.  
  41. And now suppose that we want Display to do something when
  42. the width is changed--- has there been any consideration of adding
  43. a way of doing this?  (besides changing all the direct accesses
  44. to function calls)   
  45. Or is there some way, within the current standard, to do this?
  46. I toyed with some ways that involved replacing the type of 'wid'
  47. (int) with some class that did the desired operation when assigned to,
  48. but in order to have full access to Display, it has to be a specialized
  49. class for each instance variable, and each class has to have special
  50. code containing knowledge of the offset of 'wid' within 'Display'
  51. and then it has to use that offset along with some really evil
  52. casting to find the address of the 'Display' object it resides in.
  53. Or is there an easier way?
  54.  
  55. Or shall all old code of this sort be simply converted to use
  56. access methods, and should directly accessible public 
  57. instance variables be completely avoided?
  58.  
  59. If that's the case, then I'd like to stick with some sort of 
  60. standard naming convention...  but I've seen all kinds of different
  61. variations...
  62.  
  63. So, which of these do people think is the most acceptable?
  64.  
  65.     1)
  66.         class Display {
  67.             int wid;
  68.         public:
  69.             int get_wid();
  70.             void set_wid(int);
  71.         }
  72.  
  73.     2)
  74.         class Display {
  75.             int _wid;
  76.         public:
  77.             int wid();
  78.             void wid(int);
  79.         }
  80.  
  81.     3)
  82.         class Display {
  83.             int wid;
  84.         public:
  85.             int _wid();
  86.             void _wid(int);
  87.         }
  88.  
  89.  
  90. (Are there others I'm not aware of?)
  91.  
  92. I've used all three methods at different times over the years.
  93. Although, lately, it seems that #2 comes closest to resembling
  94. the normal method of accessing the instance variables, and within
  95. the class it makes it clear when a publicly (through
  96. the access methods) available instance variable is being accessed.
  97.  
  98.  
  99. Any comments, suggestions, preferred techniques, etc?
  100.  
  101.  
  102. -- 
  103. Frank "Shaggy" Barrus: feb6399@osfmail.isc.rit.edu, shaggy@csh.rit.edu
  104. http://www.csh.rit.edu/~shaggy
  105. ---
  106. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  107.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  108.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  109.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  110.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  111. ]
  112.